完整程式碼可在 GitHub 專案中找到：Finetune-30-days-demo / day-19

在前幾天的開發中，我們持續往系統加功能：任務排程、UI、認證授權、審計日誌…
但隨著模組變多，一個問題逐漸浮現：模組耦合度到底有多高？

如果沒有明確的依賴關係圖，當我們修改某個模組（例如訓練程式），可能會意外影響 DB、監控，甚至 API 層。

所以今天的目標是：畫出整體依賴關係 → 找出耦合點 → 設計修正思路。

一、產生依賴關係圖

我使用了 pydeps 搭配 Graphviz，輸出了專案的依賴圖：

pip install pydeps graphviz
pydeps app --max-bacon=2 --show-deps --output docs/deps.svg

輸出的結果存放在 docs/deps.svg，如圖所示：

二、依賴關係解讀

這張圖帶來不少有趣發現：

核心耦合點

• train_lora_v2 幾乎連接了所有核心模組（data, monitor, db, tasks.training），是目前最大的 耦合點。

👉 意味著 任何這個模組的改動，都可能影響整個系統。

也許可以把它再切細，例如：

• train/preprocess.py（資料處理）
• train/runner.py（訓練流程）
• train/evaluator.py（評估流程）

邊界清晰的模組

• auth.jwt_utils 與 auth.audit_log → 只依賴在 API 層，沒有跨模組洩漏，這是健康的設計。
• data.analysis / validation / versioning → 組成乾淨的「資料管理子系統」，沒有直接碰 API 或 Auth。

👉 表示「資料模組」職責清晰，後續加功能（例如 dataset cache、DVC 整合）也比較容易。

潛在設計問題

• monitor 同時依賴 performance、audit、exceptions，還跟 train_lora_v2、db 都有線。

  👉 這裡有點「太雜」，建議拆成：

  • monitor/logging
  • monitor/system
  • monitor/audit

這樣就能降低單一模組過度耦合的問題。

核心流程測試

依賴圖也能幫助我們判斷 整合測試主幹：

1. 訓練任務流
   api.routes.train → tasks.training → train_lora_v2 → db → results
   → 提交訓練 → 驗證 DB 與 metrics.json 正確寫入。

2. 認證授權流
   api.routes.auth → auth.jwt_utils → api.routes.task
   → 登入 → 拿 token → 查詢任務 → 驗證 RBAC 是否正確。

三. 如何解讀凌亂的依賴圖？

依賴圖往往會看起來很複雜，但 我們不需要每一條線都看懂，而是抓幾個重點：

1. 找 箭頭最多的節點（耦合點，風險最大）。
2. 看有沒有「跨模組不該有的線」。
3. 找出 模組群（像 data 就是一個群，auth 也是一個群）。

下一步，Day 20 將進行重構並補上整合測試。